The need for business continuance and fast data recovery is acute and well known. Businesses often use multiple replication techniques to prevent loss of data, for example in case of disaster, or to meet regulatory requirements. Various replication methods in existence today include creating copies and generating snapshots, i.e. subsequent incremental backups.
One data replication method is to make a copy of a source volume and store the copy to a target volume. When data need to be restored, data on the target volume is readily available for use. A disadvantage of this type of copy method is that data on the source and target may become out-of-sync when replication is performed infrequently, i.e. the source and target data gets differ. On the other hand, frequent data mirroring to keep data in sync may be unnecessary and consumes excessive system resources.
Another replication method is point-in-time replication such as generating snapshots. An incremental backup includes only data that have changed from a previous replication. Existing snapshot systems generally maintain three volumes: source, target and journal. The source volume stores data from hosts, and snapshots of data on the source volume are replicated to the target and journal volumes. The target volume contains one or more point-in-time images of the entire data to be replicated that is stored in the source volume, i.e. snapshots. The journal volume logs data changes made from the point in time of the snapshot image in the target volume. When data need to be restored up to a specific point in time, the incremental backups from the journal volume are used to update the snapshots from the target volume up to the specified time. The journal volume is a sequential storage system, so that once a specific point in time is indicated, every item that is stored before or after in the journal volume is used to update the snapshot from the target volume, as if the target volume snapshot is rolled backward or forward.
Restoring data from snapshot to a previous desired state will typically take longer than restoring from a full copy. The delay is due to applying successive updates, i.e. incremental backups up to a specified time on the target volume to generate a desired point-in-time image. The delay may be exacerbated when there is a steady stream of I/O to and from the source volume. The frequent I/O activities on the source volume in turn, require frequent updates to the target volume snapshots and journal volume incremental backups. Especially in large enterprise configurations, busy business activities often generate frequent I/O activities on a large number of volumes. Waiting for each target volume rolling backward or forward to desired points in time during busy I/O may cause long delays to point-in-time data recovery and in extreme cases, may interfere with business operations.
There is a need, therefore, for an improved method or system that efficiently backs up a large volume of data on a computer system subject to a steady stream of I/O.